Executable models for Embedded Controllers Development - A Cloud Based Development Framework

We present IOPT-Tools, a tool framework for the development of digital controllers based on graphical executable models. The framework supports edition, simulation, verification through state-space querying, and code generation for several hardware platforms, most notably microcontrollers (e.g. Arduino, PIC, and Raspberry Pi) and FPGAs. The tool framework uses a class of Petri nets and is cloud based: the development process is performed using a browser. I. MOTIVATION AND GOALS Digital controllers are often developed and programmed using textual languages. Due to the well-known suitability of Petri nets to graphically specify sequence, concurrency, and synchronizations, specific classes of Petri nets have been designed to support the specification of this type of systems (e.g., [1]–[4]). Yet, somehow surprisingly, the ”Petri Nets Tool Database” [5] shows a notable scarcity of tools able to support the design and, especially, the generation of code for digital controllers. This work presents a web tool framework that provides a higher level language for the development of digital controllers. It is based on graphical executable Petri net models that use a non-autonomous class of Petri net. Besides supporting the modeling, simulation, state space exploration, and code generation for digital controllers, the framework is totally web based, thus providing multi-platform support and avoiding the need to install software. II. NON-AUTONOMOUS PETRI NETS Petri nets have their origin in the PhD. Thesis of Carl Adam Petri [6]. Yet, numerous Petri net classes exist, some of them with associated tools [5]. These classes of nets usually share a small set of base characteristics that we summarize next: • Petri nets are directed graphs with two types of nodes: places and transitions; • Places are the ”passive” part, are represented by circles or ellipses, and are typically associated to states, resources, or conditions; • Transitions are the ”active” part, are represented by bars or rectangles, and are typically associated to changes of state, actions, message passing, or consumption of resources; • Places can only be connected to transitions, and viceversa; • Places and transitions can have any quantity of input and/or output arcs. In its most well-known form (Place/Transition nets or P/T nets [7]) Petri nets provide support for very abstract models, which are autonomous in the sense that they do not depend on external entities. Yet, it is a well-established fact that an effective modeling of digital controllers requires or benefits very significantly from the addition of non-autonomous concepts, namely the explicit modeling of external input and output signals and events. Additionally, as P/T nets are nondeterministic, the designer must have a way to remove nondeterminism from the models. To that end, as presented next, the IOPT nets class adds priorities to transitions, thus providing a way to remove effective conflicts. IOPT-Tools [8] is based on a non-autonomous class of Petri nets, which adds several well-known and established concepts to P/T nets. The net class is named Input-Output PlaceTransition Petri nets, a name that emphasizes the supported explicit specification of input and output signals and events in the net models. The precise syntax and semantics of this net class are presented elsewhere [9], [10]. Here, we briefly present the main additions to P/T nets. Compared to P/T nets, IOPT nets add the following constructs: • Explicit modeling of external input and output signals and events; • Guards (function of input signals) and priorities in transitions; • Test arcs; • Input and Output events in transitions; • Output actions in places, as well as in transitions. The metamodel for the Input-Output Place-Transition nets reuses many of the elements of the PNML metamodel for Place/Transition nets, such as places, transitions, and arcs, and extends it to include specific concepts. The IOPT metamodel is described in RelaxNG, as well as in MOF and Ecore formats, putting IOPT in the context of MDA artifacts and allowing one to take benefit from the MDA infrastructure [10]. IOPT nets have a single server maximal step cycle accurate semantics, which together with priorities in transitions, allows the development of deterministic models. In this semantics, all transitions that can fire will fire. To that end each fireable transition has to be enabled (sufficient tokens in input places) and ready (external signals and events allow the transition to fire). III. THE IOPT-TOOLS FRAMEWORK IOPT-Tools is a framework that integrates a set of tools supporting the development of digital controllers. The framework is also being used for teaching [11], which serves as a validation of its usability and simplicity. Presently, it integrates the following tools in a web-based interface allowing cloud based storage of the Petri net models being created [12]: • Edit Model — Enter in the IOPT Model Editor tool; • Simulate the models — executing the ”token game” [13]; • Generate C Code — Invoke the automatic software C code generator [14] ; • Synthesize VHDL — Invoke the automatic hardware VHDL code generator [15]; • Generate State Space — Execute the State-space generation tool; • Query Editor — Open the Query-editor tool to specify state-space queries; • Query Results — View query results after the end of statespace calculation; • Download Model File — Download the current model file to the users PC; • Export Snoopy C — Convert the current model to the Snoopy/IOPT editor file format, using C syntax for math expressions; • Export Snoopy VHDL — Convert the current model to the Snoopy/IOPT editor file format, using VHDL syntax for math expressions; • Decompose GALS — Decompose the selected model into several sub-models according to specified GALS timedomains [16], [17]; • Model List — Select other model from the list of models stored in the server’s user account. Each model (component) can be seen as a sub-model to be mapped into an hardware or software platform assuming hardware-software co-design techniques and specific metrics, as power consumption, performance, among others. FPGAs have been used in conjunction with IOPT-Tools framework allowing exploring and exercising solutions in hardwaresoftware solution space. This allows the development of globally asynchronous, locally synchronous (GALS) systems. Figure 1 shows the login web page. After, Figure 2 shows an IOPT net model for a quad encoder model, ready to be selected among several available, and Figure 3 shows the screen for the simulator tool. Fig. 1. Login window. Fig. 2. Selecting one model to open, while presenting the one currently selected. Fig. 3. Simulation tool window. For the generation of the state-space, the user specifies the initial marking and the state-space is generated using the maximal step semantics of IOPT nets, taking in consideration the values of input signals and events. The state space can then be queried. Each query is a logical expression that can use place markings and event output signals associated to transitions. These queries allow the verification of some forms of reachability. Listing 1 and Listing 2 show part of the generated C and VHDL code, respectively, which can be directly deployed into implementation platforms, such as FPGAs for VHDL descriptions, and current popular platforms (e.g., Arduino and Raspberry PI) for C based implementations. Listing 1. Part of the generated C code 25 /∗ Net quad encode r − IOPT ∗ / 26 /∗ Automat ic code g e n e r a t e d by IOPT2C XSLT t r a n s f o r m a t i o n . ∗ / 27 28 # i n c l u d e < s t d l i b . h> 29 # i n c l u d e ” n e t t y p e s . h ” 30 31 i n t t r a c e c o n t r o l = TRACE CONT RUN; 32 33 e x t e r n vo id w e b S e r v e r i n i t ( ) ; 34 e x t e r n vo id w e b S e r v e r g e t R e q u e s t ( ) ; 35 e x t e r n vo id webServe r sendResponse ( ) ; 36 e x t e r n vo id w e b S e r v e r d i s c o n n e c t C l i e n t ( ) ; 37 e x t e r n vo id w e b S e r v e r c h e c k B r e a k P o i n t s ( ) ; 38 39 s t a t i c quad encoder NetMark ing marking ; 40 s t a t i c q u a d e n c o d e r I n p u t S i g n a l s i n p u t s , p r e v i n p u t s ; 41 s t a t i c q u a d e n c o d e r P l a c e O u t p u t S i g n a l s p l a c e o u t ; 42 s t a t i c q u a d e n c o d e r E v e n t O u t p u t S i g n a l s e v ou t ; 43 44 vo id s e t u p ( ) 45 { 46 c r e a t e I n i t i a l q u a d e n c o d e r N e t M a r k i n g ( & marking ) ; 47 i n i t q u a d e n c o d e r O u t p u t S i g n a l s ( &p l a c e o u t , &e v ou t ) ; 48 q u a d e n c o d e r I n i t i a l i z e I O ( ) ; 49 q u a d e n c o d e r G e t I n p u t S i g n a l s ( &p r e v i n p u t s , NULL ) ; 50 # i f d e f HTTP SERVER 51 w e b S e r v e r i n i t ( ) ; 52 # e n d i f 53 } 54 55 vo id loop ( ) 56 { 57 # i f d e f HTTP SERVER 58 w e b S e r v e r g e t R e q u e s t ( ) ; 59 # e n d i f